NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/7648

Text File | 1996-08-05 | 4.0 KB | 100 lines

Path: mail2news.demon.co.uk!genesis.demon.co.uk
From: Lawrence Kirby <[e-mail]>
Newsgroups: comp.lang.c
Subject: Re: const char??
Date: Tue, 27 Feb 96 20:47:19 GMT
Organization: none
Message-ID: <[e-mail]>
References: <[e-mail]> <4gb7u8$[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
X-NNTP-Posting-Host: genesis.demon.co.uk
X-Newsreader: Demon Internet Simple News v1.27
X-Mail2News-Path: genesis.demon.co.uk

In article <[e-mail]>
           [e-mail] "Kazimir Kylheku" writes:

>        int * const x;
>
>The trick is to see the declaration of the type, and the further declarators of
>objects derived from the type as separate syntactic units. Immediate
>understanding is thereafter forthcoming. :)

I'll take your word on that! :-)

> >(There is a related issue that the function may also change *x by
> >using the lvalue *(char*)x. That, and similar tricks, are so bad
> >programming practices, that I won't even comment on them!)
>
>Hmm. Is that not a bit of an error, since the const modifier is being dropped
>in the cast? C allows you to only safely convert pointers of any type to void *
>and back to the same type. I will have to check references whether or not that
>"type" is so restrictive as to include any modifiers like const and volatile.

6.3.4

"It is guaranteed, however, that a pointer to an object of a given alignment
 may be converted to a pointer to an object of the same alignment or less
 strict alignment and back again; the result shall compare equal to original
 pointer."

6.1.2.5

"The qualified or unqualified versions of a type are distinct types that
 belong to the same type category and have the same representation and
 alignment requirements."


So you can certainly cast between pointers to differently qualified versions
of the same type and back again. More simply I take:

6.3.4

"A pointer to an object or incomplete type may be converted to a pointer
 to a different object type or a different incomplete type. The resulting
 pointer might not be valid if it is improperly aligned for the type
 pointed to."

to mean that if the result *is* properly aligned (as in this case) then
the result is valid.

>In any case, the cast does make it explicit that you are trying to voluntarily
>break the const. But in your function declaration you promised that you would
>not touch the object---why go through the bother of making that promise to the
>caller, when you intend to violate it?

The cast doesn't necessarily violate the promise. Consider writing an
implementation of strchr() in C. The prototype is:

char *strchr(const char *s, int c);

It returns a pointer derived from s or NULL. Somewhere within this function
you are going to have to convert from const char * to char *. This function
does break the 'chain of constness' and if you pass it a const char * value
you should ensure that you assign the return value to a const char * variable.
To get around this strchr() would have had to return an offset rather than
a pointer.


> >An object _defined_ a (i.e. an object whose storage was allocated by a
> >declaration specifying) const, cannot be portably changed by the
> >program. A compiler can assume it's value won't change unless it is
> >also volatile: in which case, even though the program cannot write to
> >it, the compiler has to assume that its value can change due to unkwon
> >reasons.
>
>A read-only device status register would be an example of such a "volatile
>const" beast, no?

Yes. Also an object shared by different programs could be volatile in one
and const volatile in another. I can't see much use for const volatile
in a strictly conforming program however since C itself can't create objects
for which such qualification would make sense (unless you can think of
something!)

--
-----------------------------------------
Lawrence Kirby | [e-mail]
Wilts, England | [e-mail]
-----------------------------------------